1. Technical Field
The present invention relates to an improved method of developing applications for data processing systems, and in particular to provide such an improved method wherein applications are created utilizing object-oriented programming components. Still more particularly, the present invention relates to an improved method of developing applications for data processing systems utilizing object-oriented programming language within a distributed object oriented system environment wherein complex functions of a user application are encapsulated within a framework in a data processing system.
2. Description of the Related Art
A generalized structure for a conventional data processing system includes one or more processing units connected to a system memory device (random access memory or RAM) and to various peripheral, or input/output (I/O) devices. The I/O devices typically include a display monitor, a keyboard, a graphical pointer (mouse), and a permanent storage device (hard disk). The system memory device is utilized by a processing unit in carrying out program instructions, and stores those instructions as well as data values that are fed to or generated by the programs. A processing unit communicates with the other components by various means, including one or more interconnects (buses), or direct access channels. A data processing system may have many additional components, such as serial and parallel ports for connection to, e.g., printers, and network adapters. Other components might further be utilized in conjunction with the foregoing; for example, a display adapter might be utilized to control a video display monitor, and a memory controller can be utilized to access the system memory, etc.
FIG. 1 depicts the basic structure of a conventional data processing system 10. Data processing system 10 has at least one central processing unit (CPU) or processor 12 which is connected to several peripheral devices, including input/output devices 14 (such as a display monitor, keyboard, and graphical pointing device) for the user interface, a permanent memory device 16 (such as a hard disk) for storing the data processor""s operating system and user programs, and a temporary memory device 18 (such as random access memory or RAM) that is utilized by processor 12 to carry out program instructions. Processor 12 communicates with the peripheral devices by various means, including a bus 20 or a direct channel 22 (more than one bus may be provided utilizing a bus bridge).
Data processing system 10 may have many additional components which are not shown such as serial, parallel, and USB ports for connection to, e.g., modems or printers. Those skilled in the art will further appreciate that there are other components that might be utilized in conjunction with those shown in the block diagram of FIG. 1; for example, a display adapter connected to processor 12 might be utilized to control a video display monitor, and a memory controller may be utilized as an interface between temporary memory device .18 and processor 12. Data processing system 10 also includes firmware 24 whose primary purpose is to seek out and load an operating system from one of the peripherals (usually permanent memory device 16) whenever data processing system 10 is first turned on.
The operation of data processing systems of the type depicted in FIG. 1 is well known in the art. Program information comprising instructions and/or data is stored on permanent memory device 16 and may be selectively copied into temporary memory device 18 once data processing system 10 is powered on. Processor 12 executes the instructions within such program information and generates text or graphical information for presentation on display output device connected via graphics adapter, where the information may be viewed by a user. The user may selectively control operation of data processing system 10 through input entered on one of input/output devices 14.
A data processing system program is accordingly a set of program instructions which are adapted to perform certain functions by acting upon, or in response to, the I/O devices. Program instructions that are carried out by the processor are, at that lowest level, binary in form, i.e., a series of ones and zeros. These executable (machine-readable) program instructions are produced from higher-level instructions written in a programming language. The programming language may still be low-level such as assembly language (which is difficult to utilize since instructions appear as hexadecimal bytes), or may be a higher level language in which instructions are created utilizing more easily understood words and symbols.
In an attempt to simplify programming, and yet still provide powerful development tools, programmers have created xe2x80x9cobject-orientedxe2x80x9d programming languages in which each variable, function, etc., can be considered an object of a particular class. Object oriented programming is governed by the Common Object Request Broker Architecture (CORBA) standard which originates from the Core Object Model.
The main goals of the Core Object Model are portability and interoperability. Interoperability means being able to invoke operations on objects regardless of where they are located, which platform they execute on, or what programming language they are implemented in. This is achieved by the Object Request Broker (ORB), which relies on the semantics of objects and operations described in the Core Object Model. The ORB also requires some extensions to the core which provide specifications for specific communication protocols, an interface definition syntax, and basic services to object implementations. CORBA provides several extensions: Objects, defined simply as models of entities or concepts; Operations signatures (parameters and return values) where an operation is an action offered by an object which is known to the outside world by its signature. Further, an operation""s signature has the following components: a name, a set of parameters, and a set of result types. Operation signatures are unique within a particular object.
An interface is a collection of operation signatures and attributes. Typically, the interface to an object is the set of operations offered by that object. Interfaces are related to one another by substitutability relationships. This means that an object offering an interface can be utilized in place of an object offering a xe2x80x9csimilarxe2x80x9d interface. The Core Object Model simply defines substitutability as being able to utilize one interface in place of another without xe2x80x9cinteraction errorxe2x80x9d.
Since interfaces may offer operations with the same signatures that have different purposes and semantics, it is useful to have an assertion of compatibility between them. In order to ensure a semantic relationship, the model introduces inheritance. If interface A inherits from interface B, then A offers all of the operations of B, and may also offer some additional operations. The set of operations of A is therefore a superset of the operations of B, and hence A is substitutable for B.
At the heart of CORBA is the Interface Definition Language (IDL). It provides a way of defining the interfaces of objects independently of the programming language in which they are implemented. It is a strongly typed declarative language with a rich set of data types for describing complex parameters. An IDL interface acts as a contract between developers of objects and the eventual users of their interfaces. It also allows the utilization of CORBA objects to compile the interface definitions into hidden code for the transmission of invocation requests across networks and machine architectures without knowledge of the network protocol, the target machine architecture, or even the location of the object being invoked.
IDL definitions inform clients of what operations an object supports, the types of their parameters, and what return types to expect. A client programmer needs only the IDL to write client code that is ready to invoke operations on a remote object. The client utilizes the data type defined in IDL through a language mapping. This mapping defines the programming language constructs (data types, classes, etc.) that will be generated by the IDL compiler supplied by an ORB vendor.
The IDL compiler also generates stub code that the client links to, and this translates, or marshals, the programming language data types into a wire format for transmission as a request message to an object implementation. FIG. 2 depicts the concept of marshaling of data between client 25 and server 28. Client 25 and server 28 exist on opposite sides of the Object Request Broker (ORB) 27. Data from object fooxe2x80x2 26a is communicated/transported across ORB 27 via a process known as marshaling 29, whereby a serialized stream of the data is transmitted. Fooxe2x80x2 26a of client 25 communicates data with similar object type foo 26 of server 28.
IDL and IDL compilers allow programs providing and utilizing object interfaces to agree on the form of their exchanges, even though they may be developed completely independently, in different languages, and on different ORB technologies. This means that objects offering the same interfaces are substitutable, and that clients can decide which object to utilize at run time with the assurance that there will be no interaction mismatches.
Programs which invoke a CORBA object operation are generally referred to as a client. The client object interacts with a Server, which is a program that makes an object implementation available to a client. Communication between the clients and servers are usually achieved by marshaling of a stream of data across the CORBA network.
The IDL compiler generates a number of java classes known as stub classes for the client and skeleton classes for the server. The role of the stub class is to provide proxy objects that clients can invoke methods on. The proxy object method implementations invoke operations on the object implementations, which may be located remotely. If the object implementation is at a remote location, the proxy object marshals and transmits the invocation request. That is, it takes the operation name and the types and values of its arguments from language-dependent data structures and place them into a linear representation suitable for transmitting across a network. The code to marshal programmer-defined data types is an essential part of the stub code. The resulting marshaled from of the request is sent to the object implementation utilizing the particular ORB""s infrastructure. This infrastructure involves a network transport mechanism and additional mechanisms to locate the implementation object, and perhaps to activate the CORBA server program that provides the implementation.
The interfaces to components of the ORB are all specified in IDL. This provides a language-neutral representation of the interface of the ORB. IDL compilers utilize the interface definitions to create the means by which a client can invoke a local function and an invocation then happens, on an object on another machine. The code generated for the client to utilize is known as stub code, and the code generated for the object implementation is called skeleton code.
Java is an example of an object-oriented programming language which utilizes the CORBA standard. Developed by Sun Microsystems, Inc., it provides programming features such as polymorphism, encapsulation, and inheritance. Java programs are compiled into bytecodes, which are similar to machine code but are not specific to any platform. The portability, security, and intrinsic distributed programming support features of the Java programming language make this language useful for Internet programming. Java is a totally object-oriented, platform independent programming language, which achieves architectural independence by compiling source code into its own intermediate representation. Java source code is not compiled into normal machine code, but is translated into code for a virtual machine specifically designed to support Java""s features. A Java interpreter or a Java-enabled browser then executes the translated code.
Component software architectures employ discrete software components to quickly prototype and create interactive applications. Applications are built by combining a set of independent components with developer-written code which acts as a xe2x80x9cgluexe2x80x9d between components, usually responding directly to component events by setting component properties or invoking component methods. One currently popular component software architecture is the Java Bean specification of the Java programming language.
Java Beans provide a component model for building and utilizing Java-based software components. The Java Beans Application Programming Interface (API) makes it possible to write component software in the Java programming language. Components, known as Beans, are self contained, reusable software units that can be visually composed into composite components, applets, applications, and servlets utilizing visual application builder tools. A Bean is usually self-describing, including a file which contains the class"" symbol information and method signatures and which may be scanned by a development tool to gather information about the Bean, a process referred to as introspection. Any Java class with public methods may be considered a Bean, but a Bean typically has properties and events as well as methods.
Such components can be visually composed into units utilizing visual application builder tools which are utilized only to develop other programs. Components expose their features, (for example, public methods and events) to builder tools for visual manipulation. A Bean""s features are exposed because feature names adhere to specific design patterns. A xe2x80x9cJavaBeans-enabledxe2x80x9d builder tool can then examine the Bean""s patterns, discern its features, and expose those features for visual manipulation. A builder tool maintains Beans in a palette or toolbox, and a particular Bean can be selected from the toolbox, dropped into an applet or other component (such as a form), modify its appearance and behavior, define its interaction with other Beans, and compose it and other Beans into an applet, application, or new Bean, all without writing any actual code.
One example of such a tool is a JavaSoft beanbox. Referring to FIG. 3, there is illustrated a beanbox application employing traditional beanbox window functions as developed by Sun Microsystems.
When started, beanbox 30 displays three windows, toolbox 32, beanbox window 34, and properties sheet 36. Toolbox 32 contains the Beans available for utilization by beanbox 30. To work on a Bean, a user/programmer selects it from toolbox 32 and drops it on beanbox window 34. Beanbox window 34 is the area where the user/programmer may visually wire Beans together, defining how Beans appear, and interact with other Beans. Beanbox window 34 is itself an instance of a Beanbox. FIG. 3 shows beanbox window 34 with a juggler Bean instance 38 dropped in it. Beans have to be dropped into beanbox window 34 before they can be manipulated. This requires the user to click on the Bean in toolbox 32 then click within beanbox window 34. The selected Bean instance will appear, and will be selected. After dropping the Bean instance on beanbox window 34, properties sheet 36 displays the Bean properties: color, foreground, background, font, etc. Beans in beanbox 30 can be wired to other Beans which have been dropped in beanbox window 34. Beans are selected in beanbox window 34 by clicking on the Bean. The selected Bean is displayed with a hatched border. The Bean selected has significance for properties sheet 36. Properties sheet 36 displays the properties for the Beans currently selected within beanbox window 34. In FIG. 3, properties sheet 36 displays juggler Bean instance 38 properties. If another Bean is dropped in beanbox window 34, properties sheet 36 will display that Bean""s properties.
When beanBox 30 is started, it automatically loads toolbox 32 with all the Beans it finds within the Java Application Resource (JAR) files contained in the Beans/jar directory. A user""s JAR files of Beans have to be moved into that directory to have them automatically loaded at Beanbox startup. Otherwise, the Beans form the JAR files have to be loaded by utilizing beanbox 30 menu item FileLoadjar.
Builder tools discover a Bean""s features (that is its properties, methods, and events) by a process known as introspection. Properties are a Bean""s appearance and behavior characteristics that can be changed at design time. Builder tools introspect on a Bean to discover its properties, and expose those properties for manipulation. Beans utilize events to communicate with other Beans. A Bean that wants to receive events (a listener Bean) registers its interest with the Bean that fires the event (a source Bean). Builder tools can examine a Bean and determine which events that Bean can fire (send) and which it can handle (receive). Beans support introspection in two ways: (1) by adhering to specific rules, known as design patterns, when naming Bean features; and (2) by explicitly providing property, method, and event information with a related Bean information class which implements the BeanInfo interface. A BeanInfo class explicitly lists those Bean features that are to be exposed to application builder tools.
A beanbox utilizes either design pattern introspection or a BeanInfo class to discover what events a Bean can fire. JavaBeans provides event-oriented patterns to give introspecting tools the ability to discover what events a Bean can fire.
Lotus BeanMachine is another example of an easy-to-utilize visual authoring tool for manipulating Beans. This platform was designed specifically for web professionals who desire the power of the Java platform without the programming. Designers work from BeanMachine""s palette of JavaBean components linking together separate components in a drag-and-drop environment.
Traditional Java Beans and other object-oriented programming models under the CORBA standard are combined by hand to create applications. With the Java Beans, for example, the process utilizes a beanbox as described above and illustrated in FIG. 3. It requires the user to have specific knowledge of Java, JavaBean, the beanbox and the beanbox environment. The Beans can be wired together by hand inside a Beanbox type application such as JavaSoft Bean Development Kit (BDK) beanbox or Lotus BeanMachine. This process can be tedious and labor intensive. A typical wiring session for two simple Beans could entail as many as 25 separate Bean wirings (connections). A user is required to understand the events and messages that are applicable, and which objects perform what services. Knowledge of the framework, knowledge of software development, and knowledge of the beanbox environment is also necessary.
It would be desirable, therefore, to have a software application which relieves the user from the burden of learning a beanbox to accomplish Bean wiring, and understanding the framework or other types of software development issues. It would further be advantageous for the user of any CORBA component object architecture to be able to create applications without relying on complete knowledge of the architecture and the labor intensive method of wiring the components together by hand by combining components dynamically, (i.e. in real time) into user applications.
It is therefore one objective of the present invention to provide an improved method of developing applications for data processing systems.
It is another objective of the present invention to provide such an improved method of developing applications for data processing systems utilizing object-oriented programming components.
It is yet another objective of the present invention to provide such an improved method of developing applications for data processing systems utilizing object-oriented programming language within a distributed object oriented system environment wherein complex functions of a user application are encapsulated within a framework in a data processing system.
The foregoing objectives are achieved as follows. A method is disclosed for manipulating objects within a distributed object oriented environment on a data processing system. The method includes encapsulating complex issues of the distributed object oriented environment in a software generated framework. A plurality of abstract classes of objects with predefined characteristics is created for utilization within the framework. Also, a plurality of proxy objects are connected to the framework. Finally, the method allows the framework to manipulate the proxy objects to instantiate communication and data transfer between objects of the distributed object oriented environment.
In one illustrative embodiment, the framework operates to provide a means of communication between a client side object and a server side object in a CORBA environment utilizing CORBA proxies. During manipulation of the objects neither side nor the framework has any knowledge of the actual transactions taking place.
The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.